The Hacker Chronicles - A…the Computer Underground/The Hacker Chronicles - A Tour of the Computer Underground (P-80 Systems).iso/misc/v05i117.txt

Internet Message Format | 1992-09-27 | 41KB

From:       Kenneth R. van Wyk (The Moderator) <[e-mail]>
Errors-To: [e-mail]
To:       [e-mail]
Path:      cert.sei.cmu.edu!krvw
Subject:   VIRUS-L Digest V5 #117
Reply-To:  [e-mail]
--------
VIRUS-L Digest   Tuesday, 16 Jun 1992    Volume 5 : Issue 117

Today's Topics:

AIDS information diskette - Dr Popp (re: Dr Finkel's talk) (PC)
Re: F-PROT & DR-DOS 6.0 (PC)
Re: SCAN vs. CLIPPER 5.0 (PC)
Re: "Wonder-2" False Alarms in NAV 2.0 update 4 (PC)
Re: Detecting the MtE (PC)
re: SCAN vs. CLIPPER 5.0 (PC)
re: Virus or hard disk problems ? (PC)
Re: SCAN vs. CLIPPER 5.0 (PC)
Re: Zipped Viruses (PC)
Re: Help for a new(unknown) virus (PC)
Re: SCAN vs. CLIPPER 5.0 (PC)
Re: "Wonder-2" False Alarms in NAV 2.0 update 4 (PC)
SCAN 91 has drastically changed the virus names used (PC)
Re: ISPNews & Virx (PC)
Help! Does anyone know about any known UNIX viruses? (UNIX)
Teoretical questions
Re: Taxonomy of viruses
Fred Cohen (CVP)
PC pranks and trojans (CVP)
Call For Papers: 6th Annual Virus Conference

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  (The complete set of posting guidelines is available by
FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with
your real name.  Send contributions to [e-mail]
(that's equivalent to VIRUS-L at LEHIIBM1 for you BITNET folks).
Information on accessing anti-virus, documentation, and back-issue
archives is distributed periodically on the list.  A FAQ (Frequently
Asked Questions) document and all of the back-issues are available by
anonymous FTP on cert.org (192.88.209.5).  Administrative mail
(comments, suggestions, and so forth) should be sent to me at:
<[e-mail]>.

   Ken van Wyk

----------------------------------------------------------------------

Date:    Wed, 10 Jun 92 17:30:00 +0100
From:    Anthony Naggs <[e-mail]>
Subject: AIDS information diskette - Dr Popp (re: Dr Finkel's talk) (PC)

Dear Dr Finkel, I have just FTP'd the talk you advertised on comp.virus.
I have not yet read it all, however the following caught my eye and as
the misconceptions are likely to be widespread I'm posting a CC to comp.virus.

Under the "Trojans" section of your talk:
> 12 December 1989: A distribution diskette from a corporation calling itself PC
> Cyborg has been widely distributed to major corporations and PC user groups
> around the world and the diskette contains a highly destructive trojan.  The
> Chase Manhattan Bank and ICL Computers were the first to report problems with
> the software.  All systems that ran the enclosed programs had all data on the
> hard disks destroyed.  Hundreds of systems were affected.
>
> Postscript: 2 December 1991: Joseph L.  Popp Jr., 39, was arrested in Cleve-
> land and charged with blackmail, extradited to England, and charged with mail-
> ing 20,000 such disks from London about 11 December, 1989.  Prosecutors there
> decided to drop the case in November, 1991 for lack of evidence.

First I would suggest mentioning that this is the "AIDS information diskette",
as your audience may have heard of this.  More importantly a couple of factual
errors:
1   To say that "systems ... had all data on the hard disks destroyed" is an
    over simplification.  After installing the s/w the trojan element, which
    encrypted the hard disk content, was only activated after 200 reboots.
    A number of utilities were produced that would perform the de-installation
    and/or decryption of the hard disk, these were widely used and allowed 100%
    recovery for most affected users.
2   The case was not "dropped ... for lack of evidence".  It was in fact
    discontinued as the court decided that Joseph Popp was unfit to stand
    trial, ie due to his mental state he would not understand the court
    proceedings.  Apparently he insisted on putting hair rollers in his
    beard claiming that they protected him from extraterrestrial radiation!
    I beleive he was deported back to the US, but he could be rearrested
    and the trial resumed if his apparent mental state improves.

Oh, and one other minor observation, I consider "FAT table" to be an oxymoron.
(FAT stands for File Allocation Table).

Regards, Anthony Naggs

------------------------------

Date:    11 Jun 92 10:25:56 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: F-PROT & DR-DOS 6.0 (PC)

[e-mail] (Dr. Martin Erdelen) writes:

>Good morning (Central European Summertime) everybody,

>here are two questions concerning F-PROT:

>1) What does the message "invalid program" mean?

If the program is run directly under DOS, it will hang the machine :-)

Well, actually, there are several possible explanations:

     The program is a .COM file that starts with a JMP out of the
     program code.

     The program is an .EXE file, with initial entry point outside the
     code, or with the size according to the header greater than the
     actual size of the file.

>2) Several users reported problems when trying to run VIRSTOP (v.
> 2.01) under DR-DOS v. 6.0.

I have received reports of this, and am looking into it.  Actually,
VIRSTOP is currently being rewritten entirely, as I am implementing
several new features.

>VIRSTOP *can* be installed by simple command in AUTOEXEC.BAT, but then is
>reported to use up over 52 KB of memory. Can't be true, can it?

Nope - it should use less than 10K.  Actually I am considering storing
the signatures in a separate file, which should bring the size down to
3-4K.

>I am wondering why I have never seen this mentioned on VIRUS-L - after all,
>DR-DOS isn't that rare. Am I missing something?

Well, it does not seem to happen on all machines - I know of people
using DR DOS 6, who are using VIRSTOP without any problems whatsoever.

- -frisk

------------------------------

Date:    11 Jun 92 10:30:15 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: SCAN vs. CLIPPER 5.0 (PC)

[e-mail] (Cezar Cichocki) writes:

>Over installing CLIPPER 5.0 I ( of course ) ran SCAN with /AG option
>for immunization. Immunized CLIPPER said me : 'Rules not found in file
>CLIPPER.EXE', and didn't work corectly.

Nothing strange about this - it is simply a bad idea to modify
executables :-) I used to have something similar in version 1.X of
F-PROT - a program named F-XLOCK, which could be used to add
self-checking code to any program, but dropped that for two reasons -
The one you described - not all programs worked after having been
modified, and also because my approach was ineffective against stealth
viruses.  I am working on a better approach - a generic checksumming
program, which should be ready soon.

- -frisk

------------------------------

Date:    11 Jun 92 10:33:43 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: "Wonder-2" False Alarms in NAV 2.0 update 4 (PC)

[e-mail] (Matthew J. D'Errico) writes:

>Hi, all...

>I thought I'd pass along the essence of a growing thread from
>compuserve in which some false alarms have been caused by Norton
>Anti-Virus' latest update (04) for version 2.0 which was released on
>June 1st...

Well, the reason is simple - the Wonder virus is written in Borland C++,
and the signature string some scanners use (not only Symantec) just happens
to be found in lots of programs compiled with this scanner.

So, if a scanner reports Wonder, don't be alarmed - get a "second opinion",
run my F-PROT, McAfee's SCAN, Alan SOlomon's FINDVIRU or some other scanner
which does not generate a false report on this virus.

- -frisk

------------------------------

Date:    11 Jun 92 10:42:42 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: Detecting the MtE (PC)

[e-mail] (Vesselin Bontchev) writes:

>1) They "forgot" to mention the results of F-Prot (13 missed variants)

Perfectly understandable from a marketing point of view, as they are
loosing some of their biggest customers to me :-)

>Meanwhile the missed variants have been sent to McAfee Associates and
>Fridrik Skulason

I went over the 13 samples I missed, and much to my relief I discovered that
this problem was caused by one minor incorrect assumption - the basic
algorithm was ok.  So, version 2.04, which will be released any day now
(it will be distributed before the NCSA conference in Washington next week),
should have a 100% detection ratio.

- -frisk

------------------------------

Date:    Thu, 11 Jun 92 15:16:00 +0700
From:    Karel=[e-mail]
Subject: re: SCAN vs. CLIPPER 5.0 (PC)

On Thu, 04 Jun 92 20:32:16 +0700 Cezar Cichocki <[e-mail]> wrote:

> Over installing CLIPPER 5.0 I ( of course ) ran SCAN with /AG option
> for immunization. Immunized CLIPPER said me : 'Rules not found in file
> CLIPPER.EXE', and didn't work corectly.

The same happens with VirusBuster's PROTECT and WATCHDOG. These also
add a checksum at the end of a program file. There seem to be a number
of programs that don't like additions such as these. I'm sure of
FoxPro 2.0 and Clipper 5.01, but would like to hear about others. Is
there a list of these somewhere around?

+--------------------------------------+-------------------------------------+
|   Karel Sprenger                     |   Email: [e-mail]             |
|   DISC                               |          a701233k@hasara11 (BITNET) |
|   University of Amsterdam            |   phone: [phone]            |
|   Turfdraagsterpad 9                 |   fax  : [phone]            |
|   NL-1012 XT  AMSTERDAM              |   home : [phone]            |
+--------------------------------------+-------------------------------------+

------------------------------

Date:    Thu, 11 Jun 92 15:15:59 +0700
From:    Karel=[e-mail]
Subject: re: Virus or hard disk problems ? (PC)

Alan Gilbertson's advice (Wed, 03 Jun 92 17:54:46 -0400) to Andy Ravenna

> Check your CMOS hard drive setting and compare it with what your drive
> requires.  Hopefully, you can correct this and clear up the trouble.

reminded me of a friend who accidentally corrupted his CMOS and didn't
knew what the settings used to be. As this happened during the weekend
and his dealer wasn't open on monday, he couldn't use his PC longer
than he cared to. It taught him to write down the proper settings,
just in case bad luck strikes again. If only he could remember where
he put that note :-) BTW, aren't there virussen that destroy CMOS
settings?

+--------------------------------------+-------------------------------------+
|   Karel Sprenger                     |   Email: [e-mail]             |
|   DISC                               |          a701233k@hasara11 (BITNET) |
|   University of Amsterdam            |   phone: [phone]            |
|   Turfdraagsterpad 9                 |   fax  : [phone]            |
|   NL-1012 XT  AMSTERDAM              |   home : [phone]            |
+--------------------------------------+-------------------------------------+

------------------------------

Date:    11 Jun 92 12:06:00 -0500
From:    [e-mail]
Subject: Re: SCAN vs. CLIPPER 5.0 (PC)

 Cichocki <[e-mail]> writes:
> Hi!
>
> Over installing CLIPPER 5.0 I ( of course ) ran SCAN with /AG option
> for immunization. Immunized CLIPPER said me : 'Rules not found in file
> CLIPPER.EXE', and didn't work corectly.
>
> When I reinstalling CLIPPER, all was right. I repeat it few times, and
> my conclusion is : adding generic code to CLIPPER.EXE make it unusable
> ( of course I can add rules manualy, but it is funny idea, is'n it ?)
>
> Cezar Cichocki
> System operator

A better conclusion is: adding generic code to *any* program is bad news.
Clipper is just one of many programs that don't take kindly to being
modified.  If you want to use this feature of SCAN, you'd be better off
using the /AF option, which stores the information in a separate file.

    -Hutch
- --------------------------------------
Bob Hutchinson
Walter Reed Army Institute of Research
([e-mail])

------------------------------

Date:    Thu, 11 Jun 92 20:19:10 +0000
From:    007 <[e-mail]>
Subject: Re: Zipped Viruses (PC)

[e-mail] (Michael W. Burden) writes:

>Even better yet:  Make sure you get a clean copy of your anti-virus
>tools BEFORE you get infected, put them on a floppy, write protect
>it, and NEVER run these programs from the hard disk.

Always the best thing to do before starting any sort of virus scanning.

Would it be feasible to write a virus defense package that would ONLY
run after booting from a clean, write-protected floppy?  The
programming aspect is fairly straightforward, but would people accept
a product like this?  Ideally it would include a known clean copy of
DOS with it, but this could cause problems with copyright laws, etc.
A product like this could solve a lot of problems with scanners
missing stealth viruses.

  -- 007
- --
 000   000  7777 | [e-mail]
0   0 0   0   7  |-----------------------------------------------------------
0   0 0   0  7   |             Just say NO to Quantum Mechanics
 000   000   7   |

------------------------------

Date:    12 Jun 92 10:26:55 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Help for a new(unknown) virus (PC)

[e-mail] (Course account) writes:

> 1. File or Boot Sector virus
> 2. Attaches to EXE or COM programs
> 3. Increases filesize by 3K
> 4. Corrupts FAT of hardisks and floppies
> 5. Makes starting cluster of all EXE and COM programs in FAT the same
> 6. Can't be detected by SCAN 4.5B66, or Findvir(ver 4.2), CPAV(ver 1) or NAV
> 7. Mostly likely doesnot remain  in memory
> 8. Activated by running infected files.
> 9. Probable name of the virus is 'Made in India' (Wild Guess).

A few remarks:

1) If 2. and 3. are true, then it infects files for sure. What do you
mean by 1.? That it infects boot sectors too? Have you verified this?

2) There is only one virus (in five variants) which acts as described
in 5. - the Dir II virus. But it is rather well known and most
contemporary scanners should detect it. Also, it is completely
different from what your other descriptions suggest.

3) You are using rather strange scanning software - SCAN is about two
years old (which means that it is completely obsolete), Findvirus
(form Dr. Solomon's Toolkit?) version 4.2 probably doesn't exist yet
(the latest version I have seen is 4.19 beta), and the other two
programs are rather bad (and old on the top of that).

4) What is the reason of 9.? Does it contain this string? Does it
display such message?

As a conclusion, it seems to be a new virus. I cannot tell more about
it unless I get a copy of it.

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev           Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]       Fachbereich Informatik - AGN
** PGP public key available by finger. **     Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]     D-2000 Hamburg 54, Germany

------------------------------

Date:    12 Jun 92 10:53:54 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: SCAN vs. CLIPPER 5.0 (PC)

[e-mail] (Cezar Cichocki) writes:

> Over installing CLIPPER 5.0 I ( of course ) ran SCAN with /AG option
> for immunization. Immunized CLIPPER said me : 'Rules not found in file
> CLIPPER.EXE', and didn't work correctly.

The reason is that when SCAN is run with this option (and with the /AV
option as well), it adds some checksum information to the executable
files. As I have always said IT IS A VERY BAD IDEA TO TOUCH OTHER
PEOPLE'S FILES! The people at McAfee Associates are ignoring this and
see what happens...

My advice is: NEVER use SCAN with those two options. They can be
HARMFUL to your programs!

> When I reinstalling CLIPPER, all was right. I repeat it few times, and
> my conclusion is : adding generic code to CLIPPER.EXE make it unusable

CLIPPER is not the only program that is sensitive to such
modification. Any self-checking program (most anti-virus programs,
that is) will moan if "immunized" this way. And program that contains
debug information (that is, programs compiled with Borland's or
Microsoft's C and Pascal compilers) will "lose" this information (that
is, the debugger will not be able to see it), if it is "immunized"
this way. And if you happen to run a third-party integrity checking
product, it will report that a lot of executable files have been
modified - probably by a virus... DON'T USES THESE OPTIONS OF SCAN!
Don't let it modify your files!

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev           Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]       Fachbereich Informatik - AGN
** PGP public key available by finger. **     Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]     D-2000 Hamburg 54, Germany

------------------------------

Date:    12 Jun 92 11:39:40 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: "Wonder-2" False Alarms in NAV 2.0 update 4 (PC)

[e-mail] (Matthew J. D'Errico) writes:

> Several instances have been reported where this update reported
> infections of the "Wonder-2" strain of the "Wonder" virus in
> commercially distributed software...  These infections include files
> from :

>     Borland C++ 3.0 (TOUCH.COM)
>     Mavis Beacon Teaches Typing 2.0
>     Stacker 2.0
>     VCD.COM (from VCD.ZIP - shareware ?)
>     Intermission 3.0 (IMSETUP.COM)
>     SHEZ v7.1 (3 different files : SHEZCFG.COM, SGREG.COM and DUMPMAC.COM)

The reason of this is that the Wonder virus is written in a high level
language - Turbo C++, if I remember correctly. If you are not careful
enough when selecting a scan string, you may pick one from the
standard libraries that are linked by the compiler. If you do this,
then you'll "find" the virus in every program that is written in the
same language and contains a call to the same library function.
Obviously this is what happened to NAV.

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev           Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]       Fachbereich Informatik - AGN
** PGP public key available by finger. **     Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]     D-2000 Hamburg 54, Germany

------------------------------

Date:    12 Jun 92 11:45:11 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: SCAN 91 has drastically changed the virus names used (PC)

Hello, everybody!

Warning: in SCAN version 91 McAfee associates have introduced several
changes, which might cause very severe misunderstandings.

I have always said that SCAN is unreliable for virus identification -
it is only good for detecting whether an object is infected at all or
not; not for detecting with what it is infected exactly. However, with
version 91 McAfee Associates have really messed the things up.

First, they have introduced a lot of two-letter virus names - like VD,
V2, F2, etc. Needless to say, those viruses are not "documented" in
VIRLIST.TXT. But this file has never been a good documentation of what
SCAN detects... The problem is that some of the signatures for these
viruses are probable to cause false positives... :-( As a general
rule: if SCAN tells you that only ONE file on your computer is
infected and reports a weird two- or three-character name, don't
believe it - it's probably not a virus. Better use some other scanner
to re-check the results.

Second, they have CHANGED the names of many of the old viruses that
they report. For instance, W13 is reported as V2 [F2], some Vienna
variants are reported as Family [FM], the Dark_Avenger.2000.* and
Dark_Avenger.2100.* variants are reported as RKO [RKO], the Tiny
viruses and the Dir.691 virus are both reported as Pif [Pif] (these
two viruses have nothing in common), and many, many, others.

Third, they seem to have "optimized" some strings to be shorter, and
to match as many viruses as possible, regardless how these viruses are
named or whether they have something in common or not. As a result,
there is a huge naming confusion introduced and the probability for
false positives is higher. I suspect that this has been done to
overcome some memory limitations, but I don't think that the solution
used is acceptable.

The result is that when a user reports "I think that I have a virus;
SCAN 91 reports it as XYZ", this contains almost no information - it
might be a false positive, or the actual virus might be something
completely different. Therefore, any virus-competent person who reads
the report and is willing to help won't be able to understand what the
user is speaking about. The net result is that the users are less
protected and less likely to get correct information.

I strongly suggest to McAfee Associates to improve their virus
identification (and reliable detection). Meanwhile I feel unable to
provide any help to users who report a virus relying on the name that
SCAN 91 has reported. I can only suggest them to use a better
scanner...

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev           Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]       Fachbereich Informatik - AGN
** PGP public key available by finger. **     Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]     D-2000 Hamburg 54, Germany

------------------------------

Date:    12 Jun 92 10:38:19 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: ISPNews & Virx (PC)

[e-mail] (Ross M. Greenberg) writes:

> That's what last-minute-before-the-release fiddling will getcha, alas.
> We recently became aware of this, dangitall, and a new release that
> catches 10,000 out of 10,000 of our test viruses will be released very
> shortly.

As soon as it is available, I'll test it.

> >The files are not destroyed - they work perfectly and are able to
> >spread the virus. However, since the decryptor is almost non-existent,
> >it is very difficult to detect it... :-)

> I dunno, Vessilin: some of the above mentioned 10,000 viruses seem to
> trash the productivity of the target file pretty nicely: after the
> decryptor comes a whole bunch of NOP's, followed immediately by a
> return.  The target program is never run, as an exit back to DOS seems
> to preclude that pretty well.

Wait a minute. What do you mean by "some of the above mentioned 10,000
viruses"? Do you have them? I have not sent them to you for sure, did
you get them from Morton? Or are you speaking about a different (not
ours) test set? Because I had a look at some of the non-detected files
and they seem to be perfectly in order...

Meanwhile I got a report from Antony Naggs that the Pogue virus (one
of the MtE-based viruses) sometimes produces corrupted variants. This
is due to the fact that the virus is sloppily written, it is not a
fault of the MtE. In our tests we used Fear mutations. Fear is the
same as the Dedicated virus (the virus shipped in source with the MtE
package) - just the text string is patched. I have never seen it to
corrupt itself...

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev           Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]       Fachbereich Informatik - AGN
** PGP public key available by finger. **     Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]     D-2000 Hamburg 54, Germany

------------------------------

Date:    Wed, 10 Jun 92 20:26:32 +0000
From:    [e-mail] (john Guh)
Subject: Help! Does anyone know about any known UNIX viruses? (UNIX)

A customer of mine is worried about computer virus on tapes which
contained Timeplex`s application software to be loaded on a SUN
SPARCstation.

Has anyone ever heard of computer virus on UNIX systems?  Are there
any virus detection program for UNIX?
- --
==================================================================
John Guh                2411 Dulles Corner Park
E-Mail:  [e-mail]    Suite 500
Phone:    [phone]    FAX: [phone]    Herndon VA 22071

------------------------------

Date:    Thu, 11 Jun 92 12:17:00 +0200
From:    Homo homini lupus! <[e-mail]>
Subject: Teoretical questions

I hope you can help me with an answer to some question that have
been bothering me:

1) Having read some of F. Cohens work, I've seen many references to
a POset. What is a POset?

2) L. Adleman present a theorem (Theorem 3, p.366; Leonard Adleman: "An
abstract theory of computer viruses", Lecture notes in Computer
Science, vol.403, Springer 1990, pp. 354-374) stating:
    ... if for all i in N, v(i)>=i then v is absolutely isolable.
Can those of you, who have read Adlemans note explain to me, what is
meant by ">=". Does it mean that one can detect every virus which does
not shrink the infected program? And in what dimension is it to be
measured? Cohens compressionvirus example make a program smaller in
space, but as Cohen notes himself, it is a trade off between time and
space, meaning that it will be larger on the runtime dimension. Can one
then say from Adlemans theorem, that one cannot be certain to find such
virus when checking space, but certain when measuring it on the time
scale?

3) Cohen notes a weakness in his defence model S3 (p. 155; Fred Cohen:
"Models of Practical Defences Against Computer Viruses", Computers &
Security, vol.8, no.2, s.149-160, 1989 ) - S3 is based on a checksum
approch, which means that checksum( pi ) = checksum( pj ) for some
programs pi and pj of a length greater than the checksum [my inter-
pretation]. Relating that to the fact that most intregity checkers
today is checksum based, and to the discussion considering MtE and
100% detection, isn't this a fundamental weakness in the checksumming
concept.

4) When using MtE to exploid the "not 100% detection weakness" of
scan- ners, it would seem worthwhile to give one own mutation a higher
proba- bility. This means, that if five programs survive the scanning
in the first round, and each make say three times more copies of it
self than of other permutation, it will mean approx. 20 will survive
round two.  This is exponential growth rather than as before linear
growth (of course this will not increase the chance of survival in a
checksumbased check).

/BJARNE HOEGH NIELSEN ([e-mail])

------------------------------

Date:    Tue, 02 Jun 92 12:11:00 +1200
From:    "Mark Aitchison, U of Canty; Physics" <[e-mail]>
Subject: Re: Taxonomy of viruses

>>virus' taxonomy from a scanner.  Because of this, I suspect that
>>numerical taxonomy will give disappointing results in classifying
>>viruses.  It will tend to consider viruses as very different which are
>>simply rearranged or recoded versions of the same exact functional
>>structure.

Well, the latest version of my freeware BOOTID program is now
available for anyone interested, and it does seem to do a darned good
job of putting viruses into groups (even if I do say so myself :-).
Oddly enough, it also seems to spot 100% of new boot sector viruses,
although that's not what it is designed to do.

The approach it takes is a combination of looking for constant
characteristics between samples of the same and related viruses, plus
looking for the slightest changes between samples - so the last three
bytes tend to give a "family" name for viruses while the first eight
are unique (except that changes in disk size, serial number, etc
shouldn't change it, but generation counts do).

But is only works for boot sectors, and really only DOS ones at that
(it recognises a lot of non-DOS diskettes, but isn't really effective
in identifying viruses on them).  The present version still needs some
work when it comes to partition tables - the heuristics section
doesn't really distinguish well enough between good partition tables
and viruses, in my opinion (not that it is supposed to be - the
heuristics are only called in as a last resort if it cannot make a
positive identification).

So if anyone would like to run the program over any new virus they
think they have, or over a collection of BSI viruses, or help develop
the code further, let me know...

Mark Aitchison, University of Canterbury, New Zealand.

Examples of hashcodes for viruses (and some good boot sectors as
well); notice some vary slightly, perhaps due to different generation
counters, manufacture's ID, or whatever...

#30B0M0S.D9# Tony_Boot virus! (ID="IBM  3.3")
#30S4MZQ.D9# Tony_Boot virus! (ID="IBM  3.3")
#200HP5Q.FF# Den_Zuko.3.B virus! (ID="I4<12><00><01><00><00><00>")
#20IY6LP.3O0 DOS non-bootable (FDFORMAT)
#30K4MYT.790 IBM PCDOS 3.30
#2614HSU.A80 DOS non-bootable (Jandel) (ID="IBM 3.3")
#30NOOJP.B90 PCDOS 2.0
#201V4QV.BO0 DOS non-bootable (WATCOM )
#206S54V.BO0 DOS non-bootable (PNCI)
#20IS56P.BO0 DOS non-bootable (FDFORMAT)
#20MU5SU.BO0 DOS non-bootable (Norton)
#20N94NT.BO0 DOS non-nootable (ID=" Norton ")
#20QR41R.BO0 Norton Utilities 5.0
#40ZO4BR.BW0 DOS non-bootable (PC Tools)
#20BCMQO.F90 Data General DOS 2.11 (for DG/One, etc)
#305BK5P.F90 DOS 3.30 (ID="ReadRite") (MSDOS 3.30 with different manuf. ID)
#305BKPU.F90 IBM PCDOS 3.30 (used on Verbatim pre-formatted diskettes)
#305BKRS.F90 MSDOS 3.30
#30CEM4T.F90 MSDOS 3.2
#30CEM8P.F90 DOS for Data General DG/One, etc ("DGC 3.20")
#30X5MGU.F90 MSDOS 3.2
#4GM0S2P.F90 DRDOS 6.0
#4GTBSMS.F90 DRDOS 5.0 (06/90 or 08/90)
#4K0WN4S.F90 DRDOS 5.0 (2/91 Business Update)
#4OQSUHU.F90 DRDOS 6.0 (08/91 or 12/91)
#40LIOQU.V90 IBM PCDOS 4.0
#40LIOWO.V90 MSDOS 4.0
#4HUIM5Q.V90 MSDOS 5.0

[Moderator's note: I deleted the remaining 250+ lines of hash codes
for the sake of keeping the posting relatively short.  If there is
sufficient interest, I can e-mail out the entire list or place it on
our anonymous FTP archive.  Drop me a note if you want it, and I'll
either reply with the complete text, or announce its availability on
the archive.]

------------------------------

Date:    Tue, 09 Jun 92 22:50:56 -0700
From:    [e-mail] (Robert Slade)
Subject: Fred Cohen (CVP)

HISINT3.CVP   920609
                             Fred Cohen

No historical overview of viral programs can be complete without
mention of the work of Fred Cohen.

Hi Fred.

(Just kidding.)

In the early 1980s, Fred Cohen did extensive theoretical research, as
well as setting up and performing numerous practical experiments,
regarding viral type programs.  His dissertation was presented in
1986 as part of the requirements for a doctorate in electrical
engineering from the University of Southern California.  This work is
foundational, and any serious student of viral programs disregards it
at his own risk.

(Dr. Cohen's writings are available for purchase from:
ASP Press
PO Box 81270
Pittsburgh, PA    15217
USA)

Dr. Cohen's definition of a computer virus as "a program that can
'infect' other programs by modifying them to include a ... version of
itself" is generally accepted as a standard.  On occasion it presents
problems with the acceptance of, say, boot sector viral programs and
entities such as the Internet/UNIX/Morris worm.  However, his work
did experimentally demonstrate and theoretically prove many vital
issues.

I cannot, in one column, describe the sum total of his work.  In my
opinion, the most important aspects are the demonstration of the
universality of risk, and the limitations of protection.  His
practical work proved the technical feasibility of a viral attack in
any computer system environment.  (This feat was achieved within a
closed environment and could not, by its nature, have predicted the
social and psychological factors which have contributed to the
pandemic spread of viral programs "in the wild".)  Equally important,
his theoretical study proved that the "universal" detection of a
virus is undecidable.  Although monitoring and analytical programs
have a place in the antiviral pantheon, this fact means that they,
and, in fact, all other antiviral software, can never give 100%
guaranteed protection.  Without this early work, it is likely that
some toilers in the antiviral vineyards would still be pursuing that
elusive grail.

copyright Robert M. Slade, 1992   HISINT3.CVP   920609

==============
Vancouver      [e-mail]         | "Is it plugged in?"
Institute for  [e-mail]      | "I can't see."
Research into  [e-mail]         | "Why not?"
User           CyberStore Dpac 85301030 | "The power's off
Security       Canada V7K 2G6           |  here."

------------------------------

Date:    Thu, 11 Jun 92 12:38:34 -0700
From:    [e-mail] (Robert Slade)
Subject: PC pranks and trojans (CVP)

HISINT4.CVP   920609

                         Pranks and trojans

Pranks are very much a part of the computer culture.  So much so,
that one can now buy commercially produced joke packages which allow
you to perform "Stupid Mac (or PC) Tricks".  There are numberless
pranks available as shareware.  Some make the computer appear to
insult the user, some use sound effects or voices, some use special
visual effects.  A fairly common thread running through most pranks
is that the computer is, in some way, non-functional.  Many pretend
to have detected some kind of fault in the computer (and some pretend
to rectify such faults, of course making things worse).  One recent
entry in our own field is PARASCAN, the paranoid scanner.  It tends
to find large numbers of very strange viral programs, none of which,
oddly, have ever appeared in the CARO index.  Aside from temporary
aberrations of heart rate and blood pressure, pranks do no damage.

I would not say the same of trojans.  I distinguish between a prank
and a trojan on the basis of intent to damage.  The Trojan Horse was
the gift with betrayal inside; so a trojan horse program is an
apparently valuable package with a hidden, and negative, agenda.

Trojans are sometimes also referred to (less so now than in the past)
as "arf arf" programs.  One of the first was distributed as a program
the would enable graphics on early TTL monitors.  (That *should* have
been a giveaway: such an operation was impossible.)  When run, it
presented a message saying "Gotcha.  Arf, arf." while the hard drive
was being erased.

Trojan programs are spread almost entirely via public access
electronic bulletin boards.  Obviously, a damaging program which can
be identified is unlikely to be distributed through a medium in which
the donor can be identified.  There are, as well, BBSes which are
definitely hangouts for software pirates, and act as distribution
points for security breaking tips and utilities.  These two factors
have led to a confusion of trojan programs, viral programs and
"system crackers" which has proven extremely resistant to correction.
It has also led to a view of BBSes as distribution points for viral
programs.  (Recently our local "tabloid" paper's computer columnist,
normally better versed than this, dismissed the availability of
antiviral software to combat Michelangelo by saying that no self
respecting company would ever use a BBS.)  This in spite of the fact
that the most successful viral programs, boot sector infectors,
cannot be transmitted over BBS systems, at least not without
sophisticated intervention (generally at both ends of the transfer.)

copyright Robert M. Slade, 1992   HISINT4.CVP   920609

==============
Vancouver      [e-mail]         | "Don't buy a
Institute for  [e-mail]      |     computer."
Research into  [e-mail]         | Jeff Richards'
User           CyberStore Dpac 85301030 | First Law of
Security       Canada V7K 2G6           | Data Security


------------------------------

Date:    Mon, 15 Jun 92 10:37:12 -0700
From:    Richard W. Lefkon <[e-mail]>
Subject: Call For Papers: 6th Annual Virus Conference

CALL FOR PAPERS:  6TH INTERNATIONAL
                  COMPUTER VIRUS & SECURITY CONFERENCE

                  MARCH 10-12, 1993, NEW YORK RAMADA AND MARRIOTT MARQUIS

                  sponsored by DPMA Financial Industries Chapter in cooperation with
                  ACM-SIGSAC, BCS, CMA, COS, Computerworld, EDPAA-PH, ISSA-NY
                      and IEEE-CS


Approximately 500 attendees will hear 90 speakers and 53 vendors over the 3 days.

YOUR AUDIENCE:  Past attendees have represented industry, military,
                government, forensic and academic settings -
                creators and users of related software and hardware.

                They travel from the U.S. and many international locations
                and have titles such as MIS Director, Security Analyst,
                Operations Manager, Investigator, Programming Leader

TOPICS OF INTEREST INCLUDE (but are not limited to):

                - Prevention, detection, and recovery from viruses and
                          other unauthorized usage
                - Original research on this and related topics.
                - survey of products and techniques available.
                - Particulars of LAN, UNIX, cryptography, military use
                - Computer crime, law, data liability, related contexts
                - US/international sharing of research & techniques
                - Case studies of mainframe, PC &/or network security, e.g.,
                     - Chicago flooding recovery
                     - 1992 fire and other natural disaster recovery
                     - Recent court decisions
                     - Security implementation and user awareness in industry

PAPER SUBMISSION:

                Send a draft final paper for receipt by Wednesday, 12/18/92.
                Address to Judy Brand, Conference Chair, Box 6313 FDR Station,
                New York, NY 10150, USA.  Please include a small photo and
                introductory bio not exceeding 50 words.  Successful submitters
                or co-authors are expected to present in person.  Presenters
                receive the Conference Proceedings.

PAPER FORMAT:   Send one original and three copies.  When making the copies,
                please cover over the author name(s) and other identifying
                data.  Each paper goes to three reviewers.

                Type double spaced, with page# below bottom line (may be
                handwritten):  TITLE (caps); Name; Position, Affiliation;
                Telephone, City/State/Zip, Electronic Address (optional).

                Begin with a brief abstract not exceeding 200 words.

NOTIFICATION:   Written and (where practicable) telephoned confirmation will
                be initiated by Monday, 1/13/93, to facilitate low cost
                travel.  Those needing earlier notification should submit
                papers sooner and attach a note to this effect.

                You may be asked to perform specific revisions to be accepted.
                Nobody can guarantee you a place without an acceptable paper.

AT THE CONFERENCE:  There are five tracks.  Time your presentation to last
                40 minutes and have clear relation to your paper.  A committee
                member will preside over your assigned room and adhere to schedule.
                Don't hesitate to submit a presentation you've given elsewhere
                to a more specialized audience.  Most attendees will find it
                new - and necessary.  On-site schedule is duplicated early
                on first day.  If you may have a work emergency you can
                reschedule or substitute your co-author.

------------------------------

End of VIRUS-L Digest [Volume 5 Issue 117]
******************************************
 (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC  +000wo2 J (PC
Downloaded From P-80 International Information Systems 304-744-2253